This invention relates generally to data processing systems and, more particularly, to a method and system for accessing remote computer systems and operating at least one particular instance of a program running on the local computer on the remote computer system.
Many programs are currently implemented in object-oriented programming languages, such as the C++ programming language. The display icons that represent data or resources are typically representations of data structures called objects, which encapsulate attributes and behaviors. Objects are specified by definitions, called classes, that specify the attributes and behaviors of the particular objects, which are termed xe2x80x9cinstantiationsxe2x80x9d of the class definitions. The reference Budd, T., xe2x80x9cAn Introduction to Object-Oriented Programming,xe2x80x9d Addisori-Wesley Publishing Co., Inc. 1991, provides an introduction to object-oriented concepts and terminology.
Object-oriented programming languages make it easier for system programmers to implement the Graphical User Interface (GUI) concepts of icons and lists. For example, if the GUI icons are represented as object-oriented programming objects, the GUI program can be written so that the status of the icon is continuously updated. In this way, it is relatively simple for the GUI program to be written so that the icons can be selected with the graphical user input device and moved about on the computer system display as desired.
With the advent of object-oriented languages also came object-oriented development environments. Such development environments are computer programs or groups of computer programs that allow a software developer to create object-oriented programs. Object-oriented development environments typically have a palette of objects with which the developer builds an application. Each object on this palette is different and serves as a template for the developer. A palette object""s attribute settings are the default settings for that object. To use an object on the palette, the developer copies the object and places the copy on the application. The copied or xe2x80x9cderivedxe2x80x9d object has the same attribute settings as the original palette object. These development environments also permit the developer to modify an object and save it as another palette object or create an entirely new object.
Efforts have been made to establish a common method of communication between objects instantiated within a given operating system environment. For example, Microsoft Corporation has established a protocol, known as the Component Object Model (COM), which governs the interaction between software objects within the Microsoft Windows operating environment. COM provides a standard framework which permits objects from different applications to share data and functions. COM also permits a given application program (xe2x80x9ccontainer applicationxe2x80x9d) to contain multiple objects of different types. A format for control objects known as xe2x80x9cActiveXxe2x80x9d has been established to take advantage of the COM protocol. An ActiveX object behaves as a xe2x80x9cserverxe2x80x9d relative to its container application, which in turn behaves as a xe2x80x9cclient.xe2x80x9d The COM protocol manages, among other things, the setup and initialization necessary for container applications to send and receive messages and data to and from server applications.
In the context of an ActiveX control, stored data members are known as xe2x80x9cproperties,xe2x80x9d functions are referred to as xe2x80x9cmethods,xe2x80x9d and event occurrences are denoted as xe2x80x9cevents.xe2x80x9d Properties can be read from, and written to, an ActiveX control via associated methods. The interface of an ActiveX control is a set of methods defining certain input, output and behavior rules. Accordingly, a container application can invoke the methods of an ActiveX control to effect the defined behavior and access the object data.
In addition to representing data stored by an ActiveX control, properties are used in formatting the display of an ActiveX control. Events are utilized to notify a container application of the occurrence of an event, as well as to pass parameters relevant to the particular event. For example, an ActiveX control is capable of informing its container application of the occurrence of a selection event (e.g., when the user interface of the control has been xe2x80x9cclicked onxe2x80x9d).
ActiveX objects are typically implemented either as in-process servers where the ActiveX control is implemented as a Dynamic Link Library (DLL), or as out-of-process servers as an xe2x80x9cexecutable.xe2x80x9d ActiveX DLLs are loaded into the process space of the container application. As a consequence, data does not need to be transported between the container application and the ActiveX control. In contrast, ActiveX executables are loaded into a separate process space from the container application. Since there is no shared memory between such applications, data is transported between ActiveX objects and the container application. This is advantageous in the sense that an ActiveX executable does not interfere with the processing of data in the client application.
Although a number of programming environments exist for facilitating development of ActiveX controls as object-oriented constructs, each such ActiveX control operates independently of the container application. That is, ActiveX controls are conventionally installed in container applications so as not to be affected by changes in parameters of the container application, and vice versa. Similarly, the occurrence of ActiveX events does not automatically cause the execution of scripts or the like in the container application.
Early remote control systems were designed to access and take over the local computer system and run them from a remote location, eliminating any other access and remote operation, as noted in Hyatt (U.S. Pat. No. 5,307,463) and Zapolin (U.S. Pat. No. 5,122,948).
Existing systems as typified by Slaughter (U.S. Pat. No. 5,598,536) permit accessing of data from a local controller system, for example, and the collection of data from the local controller data memory, such as, sensor and other data, as well as the sending of instructions to the controller to set or control certain switches.
Still other systems, as typified by Crater (U.S. Pat. No. 5,805,442), provide for the existence of controller-based web pages which are sent over the Internet and viewed in a browser which accesses the controller as a node on the Web.
Other systems as typified by the Mercury Project papers entitled xe2x80x9cDesktop Teleoperation via the World Wide Webxe2x80x9d, and xe2x80x9cBeyond the Web: Excavating the Real World Via Mosaicxe2x80x9d which are attached hereto and incorporated herein by reference, show multiple servers which collect data, configure web pages and provide security features for communication and the exchange of control systems data with multiple clients on the Web.
Each of these systems uses the application running on the local system for control of the local control systems. The browser systems utilize the browser simply as a data input and display device which exchanges data and instructions with the local system.
However, heretofore there has not been a mechanism or system, which has permitted desktop bound programming to run on remote computer systems, in one or more instances without the need to rewrite the remote desktop application to run as a remote system and access data and instructions on a local control system.
The present invention is directed to a system and method for remote control by at least one controller for sending and receiving remote and local control system information wherein the controller gathers local control system information and transmits the local control information over at least one communication path to at least one remote computer system (client). A desktop bound program can be run on a remote computer utilizing remote data without changing the desktop software.
The client applications can be made to execute in any context that can host an ActiveX control. This has been accomplished by modifying the local runtime application, which in the specific embodiment is a window viewer, to become a local server and to provide an ActiveX control object to host the server.
The client application can be run from a browser or via the command line.
The remote computer system runs a remote software application and manipulates the transmitted local control information.
The remote control system information can be stored in the local computer""s controller memory. Alternatively, the remote control system information can be stored in the remote computer""s system memory.
The controller may contain one or more data handlers. Examples of data handlers include: a runtime database handler, an alarm data handler and a history data handler. Customized handlers can be created using a data handler toolkit.
The communication paths include secure (e.g., HTTPS) and non-secure (e.g., HTTP) paths. Multiple communication paths can be operable in a single session.